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Message Announcements 

- Technical Field - ~ : - . ............ 

The present invention relates to an announcement method and system for. 
5 Q§e1n a puBI1sf>suBscfi be architecture. I 

Background to the Present Invention and Prior Art 

Publish-Subscribe technologies are known in the art which allow users to 
monitor ^dr information and the like by listening to known information channels. In 
" 10 dur~earlier ptiblish^ application ~no" WO01 /99348 we describe a 

publish-subscribe architecture we term the Generic Announcement Protocol ("GAP"), 

~ wherein -messages-relating to- a~defined- subject- are transmitted- over communications 

channels which are listened to by listener applications. That is, GAP, and publish- 

„ subLsqrjbejte^ allow /users, to create Jphannelsjthat relate to. a , . . ... . . 

.15 ^sulyVctV;^ 

. will term a . "thread'. Usually current approaches such as TlBGO.TIBnet or Talarian 

SmartSockets I . . ... . „ .;_ ..v.- ....(see . 

' http; //wWw. talarian-: com/ industry /middleware/ whitepaper .pdf ) use hierarchical 
'"-;/:*.- — . rialnif^ " " 

20. ensure each identifier is unique across all the contexts in! which any of the object^ 
- ■ ■ . versions' 'may appear, which is* an important requirement. But there is also a. problem' 

in that the technology must also manage change of how pe^ 
... ' . company .names changed With hierarchical naming/., a chjange" at any. lex/el in : the 
. hierarchy is disastrous for. all system lower in the hierarchy, because they are usually 
. 25 ..widely distributed. . . : .;...„ .. ... %. .... v..,.- : - . ■ v.. ; . 

: f / v ^ a p proaches is that 'the' nam e" hierarch y, also TV. ". ' 

'""vdefiries^ With current solutions;' each enterprise / 

! hasi'S^ V 
- — hierarchies ;-have been-designed makes -them difficult 
. .". -V... 30^ downvvards effectively: ..apross V„ — 

enterprise boundaries. Thus current systems are practically iicnited "to deployment . 

'.. within one enterprise. Although pairs of enterprises can work-out ways. to share a ^ 

. hierarchy and manage:, new subject, creation; this'is hot scalable,to-many, qpahgipg, 
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arbitrary relationships between enterprises. It only works well if each merger was 
planned from the start. Also current approaches are designed so that new channels 
are created by system administrators for an enterprise, not just any user within the 
enterprise. Because many low-level relationships can exist between enterprises, 
5 cfiannercreatlo^^ to "con'troTTrom one departmenfln^eacfi enterpriser 

leading to frustration when what should be purely administrative steps are used as 
an opportunity to exert political/commercial controls. Current approaches also do not 
cope well where each enterprise has many relationships with other enterprise 
system, each of which is regularly changing. 
10 However, if hierarchies are hot to be used, we then encounter a new 

problem that if anyone is to be able to create a channel identifier; they must be 
assured that it is unique, and preferably with no prior configuration or registration 
requirements. 

Additionally, within indexed announcement schemes such as GAP 
15 (referenced previously), there is frequently the problem that channel identifiers are 
repeated many times within index messages, thus contributing to possible large 
index messages, and hence reduced bandwidth efficiency. 

The invention is intended to address at least some of the above problems. 

20 Summary of the Invention 

The present invention overcomes at least the latter of the above described 
problems by using an announcement thread addressing format which comprises a 
first sub-part concatenated with a second sub-part. The first sub-part is preferably 
the address of the party which generates the addressing identifier, whereas the 

25 second sub-part may be random data. An announcer apparatus may then use these 
address formats by including only those parts of an announcement thread address 
which render the address unique within the particular index message in which it is to 
be included, but not necessarily globally unique. 

In view of the above, from a first aspect there is provided an announcement 

30 method for use in a publish-subscribe architecture, the method comprising: compiling 
an index message containing a plurality of sequence identifiers respectively 
identifying a plurality of sequences of messages, each message in each sequence 
relating to substantially the same subject matter; and transmitting the compiled 



index message onto an index channel;, the method being characterised in that the 
sequence identifiers comprise at least two sub-parts, and the compiling step further 

comprises* for any sequence identifier to be included within the index message, 

incfuding within the index message only those sub-parts of a sequence identifier 
5 which are necessary to uniquely iaentlTy~the sequence identifier trom the other 

sequence identifiers included within the message 

. The first aspect has the advantage that only those sub-parts of a sequence 
identifier which are required to identify the sequence identifier within the index 
message (i.e. relative to the other sequence identifiers in the index message) are 
10 Included Th ^ the length of tHe index message arid. ... 

improving bandwidth efficiency. ... . 

- Irr a *preferred-embodiment7^the- first -aspect further -comprises- the-jstepr of: - - 

requesting the allocation of a sequence identifier from ah allocator; and receiving a 
. .^essagafroni^th requested sequenca.^ 

15 f ro aljbcatibn i pf sequence id^ 

- Preferably/ a first sub-part of a sequence identifier is a network address or 
other ..network, locator. This~ allows ibr ihe. degree .of permanence, required in^the.. . .„;. 
- identifier; whilst- allowing for a degree of control to be retained with -the .allocating ; 

r/r:r. vrr • ~ m : jjartyr;~ ™ .^z: "• :* ?r;.7:r"."* ••.t:~":;:"'":"*;:: 

[ . 20 ,~ lb an embodiment the first sub-part is preferably a Universal. Resource; 
locator (URL)v This provides advantage 

feature of a URL that it can represent both a jDrocess (e.g. a HTTP daemon) an^l 
persistent data stored on. a machine": It can also be used to represent a programrhC 
dedicated to AThID allocation,; which can be accessed through the generic process 
':. ; 25.. seryihgl^ the common gateway , 

1_~ Int erfac^^ ' "'" " [ >r llLLll- \ - . [ r '" : ' r "'- /: ' "" ; — llllllJ^— 

" " 7~ Alternatively; ^ 

advahtagesiihat it js easy for a "Human operator, to r^emb^r. - • *" * j \ ... • 
.In -other embodiments of . the invention the -first sub-part is an Internet 
. .30. Protocol.. network nr,6st .. . -r 
network entities are already allocated . with IP addresses, and hence; such an 
allocation scheme would be easy to implement.- , • / ^ , 
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Moreover, in embodiments of the invention a second sub-part of the 
sequence identifier is preferably a number, and furthermore is preferably randomly 
generated. The use of numbers allows for convenient generation by a computer or 
other machine. 

-5 From a second aspect "there Ts'^Jfovidecrah ahnduT^ement^sysfem f br"use IriT 

a publish-subscribe architecture, the system comprising: message compiling means 
arranged in use to compile an index message containing a plurality of sequence 
identifiers respectively identifying a plurality of sequences of messages, each 
message in each sequence relating to substantially the same subject matter; and 

10 means for transmitting the compiled index message onto an index channel; the 
system being characterised in that the sequence identifiers comprise at least two 
sub-parts, and the message compiling means is further arranged to operate, for any 
sequence identifier to be included within the index message, to include within the 
index message only those sub-parts of a sequence identifier which are necessary to 

1 5 uniquely identify the sequence identifier from the other sequence identifiers included 
within the message. 

Within the second aspect the corresponding advantages and further features 
may be obtained as already described above in respect of the first aspect, 

From a third aspect, the present invention further provides a computer 

20 program or suite of programs so arranged such that when executed by a computer 
system it/they cause/s the system to perform the method of any of the above 
described first to third aspects. The computer program or programs may be 
embodied by a modulated carrier signal incorporating data corresponding to the 
computer program or at least one of the suite Of programs, for example a signal 

25 being carried over a network such as the Internet. 

.Additionally, from a. yet further aspect the invention also provides a 
computer readable storage medium storing a computer program or at least one of 
suite of computer programs according to the seventh aspect. The computer readable 
storage medium may be any magnetic, optical, magneto-optical, solid-state, or other 

30 storage medium capable of being read by a computer. 
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Brief Description of the Drawings . 

Further f eatures and advantages . will become apparent -from' the following 
description, of an embodiment of the invention, presented by way of example, only, 
and by "reference to the accompanying drawings, wherein: 
"5 Figure l is a system block diagram ot fhe general system arcfiitecture in 



which the invention is intended for use; 

Figure 2 illustrates ah announcement message format used . by the 
announcement system in which the invention is used; 

!. Figure 3.. is a message sequence diagram illustrating the sequence of 
10 messages 'ffiat"afe transmitted "in an. eiribddimeht of the invention; 

. Figure 4 is a flow diagram illustrating the steps performed by an -allocator in 
- the embodiment of Reinvention; - - - - - : 

. - ' s Figure 5 illustrates a relative sequence identifier provided by an embodiment 
- .. . otthe.inventipn.;..-. - v ..:...i; — ; v .^.... r ..„_„, — . . _ v ... 



15 . . ' ; Figure."^ illustrates the^ binary format of a sequence. identifier provided by the 
embodiment of the Invention; 

. . FigureJOIusftrates. how. several sequence identifiers may: be combined into. a 

single index announcement message in! an embodiment of the invention; and - *■ 
" "~ \/7 rvR^ the; operation' of an ^ announcer in^an' . 
20 embodiment of the invention when using the sequence identifier format presented 
herein. * ... * - ' . 

.Description of. the Embodiments . .. . .. . 

An embodiment of .the invention will now- be described with respect to. 

25. Figures 1 : tp 7. . , J . . .. . : . . • ; 

• R gure • V iT fuitrafe s^a' ' pubfish- sub^ the. 
"operatfhg envirpnm will be r described' ^xf r "ihd/the" 

terminology to ^ r / 1 

in Figure 1 an announcing Application 10 is provided running on ja computer 
30 sysftem-.pn.the Jjke^(not shoyim) r The. to generate or; 

.otherwise process information which is to be announced by transmission of a 
message (an announcement) relating to a predefined subject onto a .c^on^unications 
channel:. 1 SI The scope of. the operation of the announcing application" 1 p- as "used 
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herein is deliberately broad, as the announcing application could be any application 
which produces information relating to any characteristic of any sort of entity. As 
examples, an announcing application 10 could be installed on a temperature sensor, 
and which acts to periodically announce the temperature sensed by the sensor. In 
— - — 5" another ~exa^ "be~ located " as part'of thersysterrT 

of a stock exchange, and act to announce the share price of a particular share, or 
the index level of a stock index. In another application, the announcing application 
could be used in a distributed programming environment to track the value that an 
internal variable to a program takes, and to produce information relating to the value 

10 of that variable. 

The announcing application 10 communicates with an announcer 12. The 
announcer 1-2 is a software programme forming part of a communication middleware 
that is given information by other locally running programmes (i.e. the announcing 
application 10) to announce information globally but efficiently to any interested 

15 parties by virtue of the transmission of messages onto the communications channel 
18. "Locally 1 here usually means on the same computing device, but an announcer 
1 2 may be arranged on one device to act for a number of locally connected devices. 

Additionally provided as part of the publish-subscribe architecture is a 
listener 16. The listener 16 is another software programme which forms part of the 
"20 communication mrd^ewarerit receives the messages sent by the announcer 12 on 
the appropriate communications channels 18. The listener 16 acts to communicate 
with a listener application 14, which is the application which makes use of the 
information provided by the announcing application 10. Thus, continuing the 
examples given above, the listening application 14 could be an industrial control 

25 application which acts to control an industrial process in response to the temperature 
sensed by the temperature sensor, and communicated to the listener 16 [n a 
message from the announcer 1 2. 

It should be noted here that the announcer 1 2 and listener 1 6 are completely 
decoupled, which means that the announcer 12 does not need to have any 

30 information about the identity, the credentials and the number of listeners. 

When the announcing application 10 continually updates and produces new 
information relating to the data, object or entity to which it relates at each update a 
new announcement message is created and transmitted by the announcer 12. We 




define such a sequence of related announcement messages to be an "announcement 
thread", with each individual message in the sequence being an "announcement 
version". A new version of an announcement (an announcement version) is assumed 
to contain information related to previous versions in some way specific to the 
5 application making the announcements^ " "~ 

An announcement message Js therefore, a new announcement version, of an. 

announcement thread, and could occur at any unknown time in the future. The new 
announcement version expresses an update of specific information relating to the 
. . data, objects, or entities which the announcing application. is monitoring. 
10 WithlnT slich~an; arc able to Identify 

announcement threads, being the sequence of- messages- transmit .onto. the. 

- -communications channel 18. : This is so listeners can- receive an announcement - 

message and know to which thread the announcement message relates arid thereby 
deterni^e. the, is ub|ect .matte - 
, 1 5 announcement .thread . ■ 

. Therefore; In order to allow such identification, each announcement thread is 
provided, with- an announcement thread; identifier. (AXhlD).;. which .is.; the; globally, 
unique; identifier for an ANNOUNCMENT THREAD. Within an announcement; 
... . ... --message^ "bptHTtRe announcement" threald: identifie'r7:201 ~a*nd ~the~~ announcement : 

. 20 version 202 (usually a numeric value) are jncluded, as shown in Figure 2. ... 

In order to provide for globally ■ -unique" AThlDS 
An allocator 20 is an entity th^t creates AThlbs for every new announcement thread . 
- at the request of an announcer ^ 

. communicate with the announcer 125, usually over. the. communications channel 1.8. 
25 The allocator 20.^ ... 

... „ ..sy stem' . but could in s o me embodiments be a. human. - .' ' -\ "• • 

Note " here "that" the allocator 20"^ 



- deboU^ed? an announcer ^ for the' • . 

creation of a new AThlD. - "".v." v 

f 30— V- ----- = For use .within such an architecture, an AThlD .must have certain, properties. r - _ 

Firstly, ian AthID shpuld be globally unique across all the spaces where it may 
eventually become relevant. This is because the identifier may become relevant to a 



context that did not exist when the identifier was created. Allowing listener mobility 
is enough to require global uniqueness. 

Secondly, preferably such AThlD's should not be subject to a hierarchical 
registration scheme. An obvious solution to the problem of AThID allocation would 
"""5"n5e to" creatTi^lquenaenfmWs " by "regisf enng'them wiffTa "hlerarchTcal' registration 
system with a single global root. However, open systems that allow people and 
programmes to create new objects autonomously are preferable over those requiring 
registration. Even where registration is delegated hierarchically, creation of the 
hierarchy becomes an obstacle to immediate use of the system. Also, a registration 

10 hierarchy is often perverted into a permission hierarchy by those that control it. For 
these reasons we do not favour such registration schemes. 

A third factor to-be considered- is the stability-of the- A-T-hlD. If we -reject- 
uniqueness by registration, an alternative is to allocate identifiers that are only 
unique to a pre-existing unique identifier of the allocator, then conca tenate the two. 

15 However, by doing this, we are making the identifier relative to one of its parent 
contexts. But, because every set of objects exists in multiple contexts, we then have 
to guess which parent context is going to outlive all the others. Therefore, we have 
to carefully choose which pre-existing unique identifier to use, to ensure it will rarely 
be in a context that may die before its children. 

20 "Additionally," an AThID musTbe designed in a simple manner so that they 

can be used efficiently with application such as HTTP, SNMP, LDAP that use an 
ASCII representation so an-ASCII scheme is required. 

In order to meet the above requirements, in the present invention we 
propose a preferable ASCII representation for an absolute AThID, and which consists 

25 of three mandatory parts concatenated together with the identifiers and separators 
as shpwn_.belqw: . , . _ . 

"ath:" <Scheme id> " = " <Allocator id> "$" <Announcement thread 
number> 

30 We also present a corresponding binary representation, but this will be 

described later. 

Within the ASCII representation the prefix "ath:" indicates that the string is 
an AThID, and the following string gives the scheme ID. The scheme ID indicates to 



the listener Which receives a message containing such an AThID what the format of 
the rest.of the AThID will be, and in particular what form the Allocator ID field -(AMD) 
will take. We grasent a number of possible schemes below, and recommend one of. 
them .^However/ for futuFe proofing^ include "the ability for new allocation 

•5 — sclTemBs^o^eintrotiir^ 

Following the^Schem.e.l.D field. is an sign, after which the. AHocator ID is 
included. This is an identifier or address code which uniquely identifies the allocator 
20 which generated the AThID . This is the meaningful part of the AThID, as it 
indicates to a recipient who the allocator 20 was which generated the AThID. The 
10 f brmat--of the- AIHD^ Will—depend- on the—scheme, whictr as" mentioned " will "be 

described. ,\ - ^ )■ 

1- - -Following- the -AMD -is a -"4" symbol,-- after which -there -is^ine^ded»-an- 

announcement thread number field. The announcement thread number (ATh#) may 

be any : Jm^fleMn; the 

15 .^relevant When we injro^uce "the; binaiy"^ , 
. ATh#s to avoid the . emotional or commercial attachments people; woulcj. otherwise. 

carry for certain names. ^ . . ' • • L.- z " :Vz~. 

'. r . ' 'Fot-iffi^ilin^^ of other parte of the- system, particularly binary index 
-.: represeritationsr(seeHa^ 
20" value! Theref oris,, allocation of announcement thread, nqmbers; is preferably random 
': Within: the-'^ the actual - number ^ 

meaning. Moreover,' it .will be appreciated, that, -in other, embodim^ 
be. replacedrwfth'Jett *-'^v- -v> 

In the preferred embodiment lower case insensitive text strings are used to 

25 represent the r 9R'HTC 

' headed SchT^Th- ^i5le r 1\felow) ' Tlie &j;^^/^bgr^ identif ier :may' be £riy of 6-1 5 
but Vve "only" 056 r: : OT« J c^fr"-pbjrit 0 ) from thff: i 6 ih th\S "space for recomm^ 

;7scTiemeT l!^^\^®! r 
... 'binary, and ,ASCIUTeprWentatioh) ,to be registered by the Internet Assigned- Names 

30 \ Authority JIA^V^^JllUctrlyc th P hew. "ath:" 
~ with I Mik\ 
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Some candidate schemes for allocator IDs are given in Table 1 . All but a 
couple of the candidate allocator identifier schemes use pre-existing identifiers that 
are already unique. 



SchlD 


Schfx" 


Binary 


Description ""~ 


Notes! 






width/b 








IPv4 


32 


IPv4 addr of allocator 






IPv6 


128 


IPv6 addr of allocator 






MAIL 


var 


E-mail address of owner of allocator 




1 


URL 


var 


URL of allocator 






IANA 


? 


IANA assigned allocator id (hierarchical! 






GAP 


? 


Allocator id claimed on well-known GAP channel 





5 Table 1 : Candidate allocator identifier schemes 



A first possible scheme is the use of an IP ADDRESS SCHEME. This scheme 
uses an IP address as an allocator ID and is very easy to set up. However to be 
effective it requires that the (possibly many) operators of that machine remember 

10 which AThlDs have been allocated under that allocator id. Otherwise it is possible 
that a new operator might not be told that the machine had a set of AThlDs 
associated with this IP address. That means that different operators could use a 
similar AThID for different purposes. 

An alternative scheme is the MAIL SCHEME. This scheme uses an 

15 individual's email address as an allocator ID. However an email address is not a very 
stable allocator and it could be changed and taken from an allocator without the 

allocator's con trol. _ This suggests H, s l n 9. .3 n eutr al address _]ike^ 

AThIDmaster@macdonalds.farm.com, but still leaves the problem of name changes. 

A third possible scheme is a URL SCHEME. This scheme uses a uniform. 

20 resource locator (URL) as an AThID allocator id. The neat feature of a URL is that it 
can represent both a process (e.g. a HTTP daemon) and persistent data stored on a 
machine. It can also be used to represent a program dedicated to AThID allocation, 
which can be accessed through the generic process serving all URLs of that scheme. 
Therefore, an allocator identifier can be chosen with a likely persistence that should 
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outlive all; the AThlDs it wiH allocate. A human allocator (if used) is not limited to 
■ choosing an allocator- identifier under her control and therefore in a transient context. 
- For instance highly persistent organisations can set up a simple AThID allocator 
programme accessible through their CGI. 
~ 5 . ~ Therefore, we recommend the 0 R~L scheme because a ORL can be as stable 

or as volatile as ; required, and no-one is restricted to only use URLs within their own 
contexts/ because URLs can be made available to anyone from anywhere on the 
Internet. An example AThID using our recommended URL scheme for the allocator 
identifier would look as. follows: . 

' ; <ath-: URL=http.: // www . hosting .org/ AThID? set=fa2rm$3 1425 > 

Note that an'- AThID contains- a-. URL. when~usin jj the - URL scheme for the 

allocator id, but it is not strictly a URL itself - it is a uniform resource identifier (URI), 
. fleeting all fha.definitjon 
15 . information. 1 indirectly \ to. reference configuration: 

information that locates object versions in both space, and time, even though 
. - - - announcTement timi 

most; r^ directly locate their resource either, nor do they 

20 . does not usually, locate information directly; if it. contains a, hostname it relies on 
configuration^ information - in a DNS; An HTTP, URL doesn't even contain the IP 
address of any DNS resblver even though it depends on one. However, we can still 
.'/«•; say. that* an, HTTP URL is a locator, because it only .relies on static configuration 
information that is not unique to the resource being located. An AThID, on the other 
. ;..25J:_:baQ^ 

^ . t o-the resource ih'q' uesti^ thus " an AThlD^is in bhly locating" a ~ t§s'6tifce ~ 7 

. 7 " ^wHen us¥d as.th^e corifiguratibn i informatibh cbilected 
earlier. ^ .1^^611^61688^ we have chos^nyto ensure that the syntax wd define for'ari 
AThip meets all. the requirements for. a URL,, because the motivation for most of 
30^ these^.requirements is : unchan identifiers, or locators... . . . , . , J. ... 

Where a number of AThlDs appear within one context (e.g. a list), to avoid 
repetition of similar material, we can define a relative AThID. For instance, if the , 
context had already defined the * base * URI as 
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<ath:DRL=http: //www. hosting. org/AThID?set=farm> then the relative URI 
<$31425> would suffice to specify the above absolute AThlD. Even if the base URI 
had a different ATh# appended, the new relative URI would supersede it, as 
specified in the rules on parsing relative URLs in RFC 1808 (as updated by RFC2368 

"5" lina^ftrc2"3"S6Pfa^mrrig" "again that "the ' motivations" forHrelative URL rules are 
unchanged for URIs)! Note that an AThlD without an ATh# appended is invalid. 

Within our ASCII representation "ath:" is the URI's scheme name, and is 
also optional for a relative AThlD. But if the allocator identifier is present, it must be 
preceded by its own allocation scheme identifier {e.g. "url="). The allocator 

10 identifier deliberately does not start with a "//" signifying that there is no network 
location and we are not using generic resource locator syntax, preventing further 
processing as a relative URL. However, the URL used for the allocator identifier may 
itself be relative to a base URL, if and only if the context of the relative URL of the 
allocator identifier is clearly distinguishable from the context of the whole AThlD 

15 URI. 

When the optional "ath: " prefix isn't present, the resulting relative AThlD 
bears a passing similarity to the URL of a non-AThID scheme. However, a valid URL 
would start with «url:" not «orl=". Because of this potential ambiguity, this 
relative form must only be used in contexts where only an AThlD would be expected 

20 by human users. 

Having described the ASCII representation of our preferred AThlD format, 

we now describe a binary representation. 

The proposed binary representation of an absolute announcement thread 

identifier (AThlD) is similar but not the same as the ASCII representation. One 
25 difference is that the context in which binary representations will be used make any 
.- - prefix like-^ath:" redundant. A binary AThlD consists of three parts concatenated 

together (we use * | ' to represent concatenation): 

<Scheme id> | <Allocator id> | <Announcement thread number> 

Here, the ANNOUNCEMENT THREAD number (ATh#) is a 1 6 bit integer. ATh# = 
0 is reserved. Additionally, the SCHEME ID is a 4 bit integer, with only one code-point 
defined, SchID = 1 meaning the URL scheme already recommended above, as 
shown in the * SchID' column of Table 1. 
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The. form "of. the allocator identifier depends on which schema, identifier is; . , 
used. Clearly, if the IPv4 or -IPv6 schemes were used, the allocator identif ier wo^'ci 
" simply be the 32^or 128 bit IP address respectively. For the URL scheme, the. 
allocator identifier is just the string of octets that are identical to the ASCII allocator 

: 5~id: : : ; ; : 

Relative- binary AThlDs as described above would be expected to be 

extremely common. They must only consist of the ATh# alone, resulting in a simple 
binary representation as shown in Figure 5. Here it will be seen that only the 16-bit 
. Ath# is given. . 

10 " - fhS albove dHinitions of the ATHID parts do hot give any c^'oasf^l^^tt 
width of an absolute binary. AThID, unless the scheme identifier implies a fixed width- 

_ tf'iQCTWriti^^ 

we recommend using the representation convention shown in Figure 6 for binary 
vr ...: L . -AT hlDs in-proto cgls, and in parti cular jn, binary an nouncement messages. , .. : ^^ : ^ :r ^_ rr ^—^_ 
15 " V. r an absolute .. ... ..■ 

distinguished from a relative one (recall that zero is a reserved value for the ATh#).- 

T\\e r 1 2 bit AliiD : aengthl f ield gjyes -the : length of the AMD f iejd I iri 32 bit xhui^ks,. 

j; maklna .thM maximumjan efficiency, Jt : would be 

20 limit .to; URL length,; in practice most URL handling software has a ■limit-.. .Very early.. 

' versidnsrof -so^fi'Mb^d^dnved * browsers had a 256 character URL limit; while. 
- Microsoft- Internet tkp^Tbr-jLv^S ;at.iea?t-).has' a- Hm'rt of 2,083 characters., .Server 
_ ; software may also be Ijmit^ can handle up to about 8kB URU). , 

. For AMDs that do not require ^ whole multiple, of 4 octets, the. remnant is padded 
...J- 25..; witb zeros;. AIL ASCJI aliocafor. identifier .schemes should riot, allow t£e_ niilj ;charact^x ; ;., ^ l. 

id , bijt it ^aves khbwfedg^. dFn&W "sdhetfie. ids 7 having to be embedded iri prdtocol ' ; 

'.. ' [ "^parsers/JV^^. . . . /. ' : v _, . * ; J . . : - : v v- v:' : .y'-,<r;~;- : . 

- - - The: "binary AThlD convention/ set out above inescapably means that the ; 
;..„ 3Q: v ivi/idthr:of:.a unpredictable without-dreading the first-^ord, pars ing- ;;;^r 
then reading ' the second word if necessary, then parsing that too. However, given 
_ _ \ _ . : t^ are concerned about performance , 
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issues, because index announcements are processed very repetitively but we need 
not be concerned beyond a certain point. 

We now give an example of the use of this binary representation in an index 
announcement message, with reference to Figure 7 which shows the binary layout 

5- ^ o'f"tRe~ pay I6¥d ot sue fT~a~m es s a g eT ' An Tnd^^^n rToTi ncefrienf Tffess ag e~is simply* a" 

table of AThlDs against their respective version numbers, which are 16 bit integers. 
Index announcement messages as used in the context of the GAP publish-subscribe 
system are described in our earlier International patent application W001/99348, as 
re f erencec j earlier, the contents of which necessary for understanding the format and 

10 use of index announcement messages being incorporated herein by reference. 

Within an index announcement message each AThID may well have a 
different allocator ID, but relative AThlDs may be used nearly all the time, because 
each listener of the index has been previously told that the absolute AThID they are 
interested in will be in a specific index announcement on a specific channel. 

1 5 Therefore, as long as it is unique within the index, each ATh# will imply the absolute 
AThID that ends with that ATh#. Therefore, all the index announcer has to do is 
include the absolute AThID for any pairs of AThlDs that happen to have identical 
ATh#s. Thus the payload of an index announcement might look as shown in Figure 
7. 

20 Here, Ath#_4 would appear twice, so the announcer qualifies both 

occurrences of it with the full, absolute AThID specification. For all the other AThlDs 

(1-3,5,6) the short, relative AThID is sufficient. 

If it became necessary to continually repeat an allocator ID because of a 

clash, it would be possible to define an abbreviated symbol for it, as is done in XML 
25 namespaces. In a way, this is similar to the internal symbols used when compressing 

data.. 

Figure 8 illustrates an example process to allow an announcer 12 in a 
publish-subscribe system architecture such as that shown in Figure 1 to perform the 
above described operation using relative AThlDs to reduce the size of index 
30 messages. 

Firstly, imagine an announcer 12 is to compile an index message for 
transmission on the communications channel 18. The announcer 12 will have been 
in contact with one or more announcing applications 10 and will have received 




indications from, them that a respective announcement for tjiose . applications is 
required; Preferably, an announcing application 10 passes announcement information 
to the announcer. 1.2 . regarding . the . .AThlD---. and., version ..number- for^. each - 
""' announcement which it requires. The announcer 12 receives this information from 
S — each announcing application wfiicfTit serves and stores rTfor use wnen compiling a~ 

. . new. index .message. •• - • 

In order to compile a new index message the process shown in Figure 8 may 
be used. Here, first of ail the announcer 1 2 retrieves the stored information regarding 
those AThlDs and version numbers for which announcements must be made at step 
10 8:2:. Then, at 'step 8;4' for each ret'rievetf 'ATh'ID •i'h^~versron~ number r check-ls 
performed to see if the Ath# of the AThlD is already in the index message. If not 

-then -it— is- determined that ; the- • Ath#- •-hsel^wlH^t>e; ^ufflctort" to- ide ntify -^ e- 

annpuncement thread within the index message without any further information 
being requir ed, and herjce processing, proc eeds Jtc^ 
"l5 the version number from the AThlD are placed into the payload of the index message 
(see Figure 7). Then, processing proceeds to step 1 8.1 2, wherein it_ is determined 

. . . whether or not- there are any. further;. 5PJ[!L 6 !dl7°?n)l^r!H^°"J^ "PiSF^ -TJ—KS- 

• message payloady and if so then processing proceeds back to step 8.-2, and" the 
: "r^dWufeT»SlTO -SgaTn;. Essentially;, step-8:i 2; causes th^^rbcesf:td b err epeated, for_ 
20~~ every announcement which the announcer has. buffered, and waiting announcement, 
r v Returning to step 8.4,- if it is determined here that an Ath# is already within^ 
the Plyjioad of "the index message being compiled then it will be necessary to include 
further information relating to the AThiD of the announcement to be included within, 
themessage, if the announcement is to be capable of ; unique identification. Thus/lf 
25 thisjs ijjstefcmined to. be the case at step 8.4 then, prpcesslrig ..Pr oc .eeds to;s^ep J^. 
j^Z^ji *" e announcer's loca l. 



-"' memory, "store, and 'at step 8.8 the full AThlD is then placed within the index 
- : messag"#p 

to whether alt of the announcements have been included in the message payload is 

30-. made> as described..aboye., : ^-- - -- - --- ... ----—,-•*•>" K--£.*-V-^: fr:: - -':~>r~J7: ' 

""■ Following the procedure outlined above, the full AThlD is only used in the 
announcement message when it is necessary because , an announcement with the 
same ATh# as an announcement to be included in the index message is already 
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present therein. At other times, only the ATh# is used, thus resulting in a much 
reduced payload within the index message than would be the case if the full AThID 
were to be used for every announcement. 

Having described the AThID format provided by the present invention, and 
5" also Tile* operatiorT"of ah~annouric~er~wK 

operation of an allocator program which is able to perform the task of the allocator 
20 in the architecture described above. 

A managed allocator programme could be very rudimentary. It would only 
need parameters that allowed a user (i.e. an Announcer 12) to perform the following 
10 functions: 

i) Register new AThlDs (respecting the above requirement that the choice of 
ATh#sis not' biased to certain parts of the number space); — 

ii) Unregister an existing AThID (see later); and 

iii) There may also need to be methods to create and destroy sets of AThlDs 
1 5 (e.g. the set 'farm 1 in the example above). 

An allocator programme might optionally support association of textual 
strings with AThlDs as they are created, in order to provide human-readable 
descriptions of announcement threads. We will discuss the association of a textual 
string to an AThID (XML file) in the example operation given below. 

20 Returning to Figure 1 , imagine that the announcing application 10 requires a 

new AThID. In such a case a request for a new AThID will be made from software 
associated with the announcing application, to the allocator 20. 

In order to do this, within the described embodiment the announcing 
application generates a human readable description of the information to be 

25 announced. This is a description of the subject matter of the announcement thread 
to .which the. desired AthID will be applied. The description could J>e a simple. .txt file 
or a .doc file etc. However our suggestion is to use the extensible Markup Language 
(XML). We use XML because it offers a unique combination of flexibility and 
simplicity by both humans and machines. 

30 An example human-readable description of the information XML file is given 

below: 

<?xrnl version= u 1.0" standalone="yes " ?> 

<HEADER> < HEADL INE > GAP Announcement < /HEADLINE > </HEADER> 
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<FROM>alice@company . com</FROM> 
<DATE>.2/.2/2003</HATE> -. 
<ITEM> 



-5 — <DE SCRTPTTON:? — S-tandaxd version — for — 3G — protocol re-tease— 3-rO 

</DESCRIPTIGN> ;*•'.. ■'. . - • 

< VALUE > 123986 </VALUE>| 
</ITEM> 

The description of the announcement thread is contained in the sections 
10 ffiarfea " ^DESCRIPTION^" "the "section ry " ■ 

marked <VALUE>. represents a random number that is used to generate different . 

ATh#. If two announcement-threads-with-different-^escri^ 

same Ath#, then the random; value : is changed by the allocator 20 in . order to 
maintain .the uniqueness of.. t^ 

1 5.. random number simply; for datalh^n^ing' prpc^ss treasons. " ...... .._ . - . : . - - 

- The request from the announcing application 10 to the allocator 20 consists 
of an HTTP request/repjy asJll^ The apnpuncjng -'^jjji^aiLjlQ • 

sends a POST request containing ^f;1^e VRL bfjthe ALLOCATOR,. the -pr^pro^vMtonjj . 
-.. . and a~ MIME-like".^ ot"ther:infprmatiorr:td- &«."7 ~~ - 

2cT^ announcedT^e~.selivef running the allocator program then subsequently; responds 
with a atatus-'' iihe;--.including'tne- : ^ssage , s- proto'cbi- version ahd^ success:, or^ 
code, followed by a MIME-like message containing the information of the AThlQ that 

has beep allocated; •"• ■' ': ,:l-i."-v. ... 

In more, detail, the HTTP communication is. initiated by a user ag#nt 

25-,. associated with ^.jaivmy^n£'S^F^o r }-. 1 P..^ n i .?:.^^S^.i t 9'J? 9 . . 

: "! applied to a ^ re^r^^on^m^se^rrThe HTTP'con^m^ ". . " : 
over TCP/IP cdnh^fibris. The^del^ulir ^brf ls TCP 80, ; but other ports" can be" Used. 7 
* •"" This dbes^hot preciudfe f?X?f " a HX ^ n ^?*°*?°l^ 

on the Internet! or on other networks^ HTTP only presumes, a. reliable transport; any , .. 
30 _ protocol • that . provides such, guarantees, can . be. used. Jn this, design we. use HTTP„ j ._ . 
v1.1 but other version .could be used. . 

The POST HTTP method is used to request tha^ the a 
accepts the entity enclosed ifi the request as a new subordinate of the request URL 
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in the request line. POST is a HTTP method designed to provide a block of data to a 
data handling process. If the entity enclosed is passed correctly to the data handling 
process in the allocator an OK answer is sent back including an entity that describes 
the AThlD. 

~ ET UpoTT receipt "of ""fHe" POST reque8f7 v fhe"Sllb^toY''20"th'en performs the 

following steps (more precisely, the host computer hosting the allocator program 
performs the following steps under the control of the program). 

Having received the request at step 4.2. the next step (s.4.4) is that, if 
required, the allocator ID is generated. Usually this step would not be carried out, for 
10 the reason that the allocator ID is preferably a pre-defined URL (or email address or 
IP address, as we describe above). However, in some embodiments both a new 
allocator ID and an ATh# may be combined to form an-AThID, and hence this step is 
provided as an optional step. 

Following step 4.4, at step 4.6 the received XML script which provides the 
1 5 human- and machine-readable description of the subject matter of the announcement 
thread is stored in a local store 22 provided at the allocator 20. This is so that a 
record is kept at the allocator of the announcement threads for which an AThlD has 
been issued. 

Next, at step 4.8, The allcoator program then hashes the description 
20 contained in the XML file and the random number contained in the value field" to give 
the Announcement Thread Number. That is, the ATh# is given as follows: 
ATh# = md5(XML < DESCRIPTION >, XML <VALUE>) 

As we mentioned above, an ATh# preferably consists of 1 6 bit, although the 
preferred hash function is MD5, which gives a 128-bit output. The output of the 

25 hash function is therefore truncated to the first 1 6 bits to obtain the ATh#. 

Following, the generation of the ATh#, a check is performed next at step 4.9 
to check that the generates ATh# is unique in the context of the particular allocator 
(note that it does not have to be globally unique across all available allocators, but 
only unique in the context of thr allocator ID with which it will be combined). This 

30 check is performed by matching the generated ATh# with previously generated 
ATh#s, which are stored in the local store 22. If it is determined that in fact the 
generated ATh# is not unique i.e. the allocator has produced that ATh# before and 
has combined the ATh# with the same allocator ID which is to be used in the 



present case, then a- different ,ATh# must -be obtained. This is produced by 
generating a further random number value which is then - substituted into the 
<value>_field. of .the.XML script; and the hash function is applied to this modified 
data to give a further hash value, which is once again truncated to 16-bits. This 
— — g turther ATFi# value is then compared to see TfiFisUnique witfiirTthe given context. 

This processes repeated until. a unique ATh# is obtained. ... .... . , 

Having obtained a unique ATh#, next at step 4.10 the whole AThID is 
generated by concatenating the obtained ATh# with the allocator ID used by the 
allocator, As we explained previously, the allocator ID is preferably a . URL. The 
10 CQncatenatToiT according" to "We AThID format described previously; and' 

hence an AJhl.D of the form: m . . . 

-- — - — "ffcfeb ; *JL— -<&Seheme -id>-» J, =J'— <Al-i-©eafe03? 1 id^>- u $ , i — ^AB^Gu^a-eeme-nfe- 1 

. thread ' nurrib,er> .. 

as an ASCJi .representation, b i. 

15 „<^Sch6rrti id>; "|.<A!!pcatorjd.>. | .< Announcement thread n.umber> 

for a binary representation is obtained. . , 

, . H^ing generated the. ^ V." . 

the i generated; A+hID in the. local store 22. the AThID is stored referenced to the 

"XMlrdes;c^ for' Which, iris generated /.As" discussed . " 

20 above, the purpose of storing the, AThID. is to allow a comparison, ot newly generated .... 
. AThfos -'with previously generated AT^^ - yy e . . : 

^ : ; ..^inblly>_atstep 4; 14 the allocator 20. transmits the generated AThID back to 
the requesting :anriouncer as part of. the OK ..response t^ 

announcer 12 can then use the AThID. in any.ahnouricemerit messages belonging to 
, . 25 . the. announcement t^ ...J .. . i*V- ■ . 

" W"e : - .now :descr1b£" fufthbF. : ^mb ~2llllll 

functlqnalify^ " ;> -" J lr *7 "* • 

'^f " ""^^^ -"^^f^^^^fF^^O* ^5s»criB&id-riBSli<*ii^tt" doefaE ncrfc indUdg security required 
Therefore, in another embodiment -the session is, initiated, using HTTP pro^ 
30 ; the jcnown Sefcurity Socket Layer, Jh . such. a . case , 

of the announcer that has requested' a new: AThID. Exploiting this option the 
... .. ..-"®J!S9!?I®rjJ^5![ e .? fc 5 h ?. *^-.t!!® ^£?.°S?i. ec, _ with the. certificate of the announcing 



W42- 




20 



application. This option gives the possibility to the allocator to restrict the allocation 
of AThlDs to specific announcers. 

A further embodiment makes provision for the prevention of Denial of 
Service (DoS) attacks. A simple DoS attack could prevent the above described 
T~^bo"d1ments*from working propeHyTA^TiFiouTamibuncer could flood an allocator 



with different AThID requests. The allocator would in the normal course of operation 
as described above allocate as many AThlDs as the number of requests. In this 
scenario the number of useless AThID allocated would be very high reducing the 
space and the resource for real AThID. 
10 In "order to mitigate this attack scenario, in a further embodiment we require 

that the allocator 20 after sending the HTTP OK does not store the ATHID but 
instead requests art -acknowledgement from the announcer containing the previous 
and the current random number. If the requested acknowledgement is not received 
the allocator times out the request. With such a simple method we require the 
1 5 announcer to maintain some computing resource for each AThID request sent, and 
hence it will not be possible for the announcer to flood the allocator with AThID 
requests. 

In a further embodiment, an announcer could have the ability to allocate a 
large number of ATHIDs tb a specific announcingjjpplication: in this case the AThlDs 
20 "could all be" "regrouped "undeTa "specific context (for example a directory in a URL). 
For commercial reasons it may be important that the user does not specify the 
specific context, it is the allocator that provides this function. For example an 

allocated AThID could look like: 

<ath :URL=http : //www. hosting . org/AThID?set=farm$31425> 

25 In this example the allocator has allocated a specific set of ATh# called 

"farm" for. a specific. announcing application. 

A more complicated embodiment could provide the feature of creating a set 
of AThlDs without receiving requests from the announcer. In this case we require 
the allocator to ask for feedback from the listener population and to aggregate 

30 together in a specific set AThlDs that have similar interests. This option could be 
very useful since it allows the creation of logical structures of different ATHIDs 
based on user experience: in this case based on user feedback. The only information 



required from the announcer is the XML file that can be used together with user 
feedback. ^ ...... . . - . , . ... 

... . -Such, a spheme.could. be very useful, to. allow searching of similar ATHJDs. 

without the need to go to the announcing application (for example in a search 
5 engine)" 

We turn. now. to. the . issue of how to deregister an existing AThlD The .. 

process of deriegistration is difficult to define. The problem is that an AThlD can be 
used by different applications. Different applications could use the same AThlD to 
exchange particular software updates in different and separate contexts. A single 
10 " user ^ it could be" used'by - t~-~ 

another application that the user cannot control. However there are requirements to . . ; 

- -deregister ;^ri -AThlD -because -it could- become -obsolete after a eertain amount- of - -.• 

time. ;* . . 

. _ ln.„order;.tb^ get^around^the^aboye. problem "we. .propose two methods that '~ * 

.15 alioyy users" to d^ ..J- * "v.. '..C- : J^-i^-- 

i) TIME TO LIVE (TTL); In one embodiment the AThlD is associated with a 
particular .time : to-ljve that is stored on .the allocator. This, time-to-iive information 

- represents aKtinne stamp (dateh after ^ which the AThlD will be discarded. To -avoid an- - 
. VAThlD'be^ 



.20 message can be .transmit . by any announcing applications that are using the specific . 
AThlD. As soon as "the TTL isfrehewed the " allocator cari announce such to other v 
announcing applicatiohs. If the TTL is hotTefresh^ before the deadline the.AThlDi.is • 
. . .. silently discarded; by7 the allocator. . . ,.'„ . . _. . 

- ii) Announcing. /application, owns the .ATHID'. In this ..embodiment only, a . . 
,25 specific .announcing a PR!l? a Jt ii ?n,.9?P..^ M se *D£j™*nagtr - a .P a ^ icu,ar ;ATHIQ. The : . ... 

: 2 announcing Vvheh" to "delete ah annpuricemient." The, "effect of. : ' T 7 . 

* an" ATHID ^discarded does* *n6t Influence other applications" because it is only : ~ 7 

- The" impiementatipn of* this scheme requires a -"POST HTTP, message 
30 containing the parameter of.the. ATHID. to.. be. deleted. Iljsjmportant that the option 
to delete an AThlD is only allowed when a security scheme in place. 

in conclusion/ therefore, the addressing scheme we describe is particular 
efficient in :a.sc4riar16 such as GAP, where an Ath# has' to maintain is. uniqueness , 



... _ : . _ 
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properties within a well-specified Multicast channel, and the full AThID is only used 
when a collision is present on the channel. Notice here that an address (if needed) 
can be referred to a particular user/machine but this is not in the requirement. 

With regards to the application of the invention to other messaging 
"T~1 scheme7,~largVTcal^ 

accessible everywhere in the network in an efficient and unique way. The addressing 
scheme we have described uses a process that allows a stable and unique identifier 
to be used by different messaging solutions in a seamless manner. The same AThID 
can be used to address the same information on different platforms and provided by 

10 different users. 

Our addressing scheme provides two main advantages: 

i) The ability for anyone to allocate an AThID using anyone else's allocator, 
allowing an allocator of suitable stability to be chosen for each thread in question, 
rather, than having to use one in one's own (possibly insufficiently stable) context.; 

15 and 

ii) The ability to generate announcement addresses comprising a generator 
ID and a preferably random announcement ID, and allowing these two parts to be 
exploited differently depending on the specific context. 

We conclude with an example of a possible commercial use of our 

20 addressing scheme. 

Here, an organization that is renowned in terms of stability allocates a stable 
allocator ID to be used for AThlDs. For example, we may imagine a general identifier 
for software updates for the 3G protocol being provided by a stable organisation 
such as the IEEE, which allocates a unique identifier for this subject. Thanks to the 

25 generated Announcement Thread Number being combined with the allocator ID the 

... - resulting. AThID is- random -enough to. avoid, ownership disputes in the future, 
(characteristic of the classic URL scheme). It is important to notice that the 
resources of the stable allocator are separated from any other resources when the 
AThID is used, such that organisations like the IEEE are not discouraged from 

30 offering such a service. The service consumes a microscopic resource and never 
requires them to arbitrate over ownership of names. 

Unless the context clearly requires otherwise, throughout the description 
and the claims, the words "comprise", "comprising" and the like are to be construed 
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in anjndusiye as opposed to- an exclusive or exhaustive sense; that is to say,, in the 
sense of "including, but not limited to". 
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CLAIMS 

1. An announcement method for use in a publish-subscribe architecture, the 
method comprising: compiling an index message containing a plurality of sequence 

5— identifiers "respectively identifying- a" plurality -of- sequences* of" messages" each 

message in each sequence relating to substantially the same subject matter; and 
transmitting the compiled index message onto an index channel; the method being 
characterised in that the sequence identifiers comprise at least two sub-parts, and 
the compiling step further comprises, for any sequence identifier to be included 
10 within the index message, including within the index message only those sub-parts 
of a sequence identifier which are necessary to uniquely identify the sequence 
identifier from the other sequence identifiers included within the message. 

2. A method according to claim 1, and further comprising the step of 
1 5 requesting the allocation of a sequence identifier from an allocator; and receiving a 

message from the allocator containing the requested sequence identifier. 
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3. A method according to claims 1 or 2, wherein a first sub-part of a sequence 
identifier is a network address or other network locator. 

20 " ~ 

4. A method according to claim 3, wherein the first sub-part is a Universal 

Resource Locator (URL). 

5. A method according to claim 3, wherein the first sub-part is an email 
25 address. 

6. A method according to claim 3, wherein the first sub-part is an Internet 
Protocol network address. 

30 7. A method according to any of the preceding claims, wherein a second sub- 
part of a sequence identifier is a number. 

8. A method according to claim 7, wherein the number is randomly generated. 



9. . A method according to claim 7, wherein the number is produced by applying 
a hash function -to data defining the subject matter, of -the sejquen.ee of -messages. 

"5— ' — : : — : : ~ : — : — ^— : 

.10... A Qpmputer program or suite of computer. programs arranged .such, that .. . 
when executed on a cpmputer system it or they cause the computer system, to /**"" 
operate in accordance with the method of any of the preceding claims. 

* 10 v 1 1. - ": A —computer readable 1 * storage medium "storing the~ -computer progranr-or at 

least one of. the suite of computer programs according, to claim .1 0. . ... . ... 

12. An announcement system for use in a publish-subscribe architecture, the ' 
^systemJQQQ^ meahs_arraraed ;in .. 

1 5 message;; cpntainmg a plurality of sequence identifiers ^ * 

plurality of sequences of messages, each message in each sequence , relating to 
.. . .. substantially ;the_sajinq subject . matter; and., .means. ^ 

index message. onto an index channel; the- system being characterised in that the 
/ sequence ..identifiers.; comprise;;at; least: : two" subparts; ;;gnd: s this^m 
20~ means is further ; arranged to operate,, for any sequence, identifier ' to be; mpiuded. 
within the index message, to include within the index message only those sub-parts -« 
of a sequence .identifier which a necessary to uniquely. identify the. sequence- 
: . . identifier, .to within the message.. ' [ . 

_25_JP3^ A :: system; ^according to. claim 12, and fyrther. co^pnsjng J^^^_ ^pr ^ .. 

requesting the ^location of a sequence ide^ and . "means for ; 

>A " ;receiving~a rriess^ge from the allocator containing th£% identifier/ " • '* * " " r * 

.14.-*..-, A* system: according to . claims, 12. s orJ.3,:-w.herein- a. first sub-part., of. .a-,. ..... .. 

30.. .sequence identifier Is a network address, prother network jopatpr. " _ . . . _ 7, : ; t , 

15. A. system according to claim 14, wherein the first. sub-part is a Universal.. 
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16. A system according to claim 14, wherein the first sub-part is an email 
address. 

5- - 1-7- A-system-according-to-claim-1-47~whereirr-the -first sub-part is- an Internet 

Protocol network address. 

18. A system according to any of claims 12 to 17, wherein a second sub-part of 
a sequence identifier is a number. 

10 

1 9. A system according to claim 1 8, wherein the number is randomly generated. 

20. A system according to claim 18, wherein the number is produced by 
applying a hash function to data defining the subject matter of the sequence of 

1 5 messages. 
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ABSTRACT 1 " 
Announcement Thread Addressing 

An Announcement^ comprises a first sub-part 

—5 — c-d^-cateTT^ 

address of the party which generates the addressing identifier, whereas the second 
sub-part may be random data. An announcer apparatus may then use these address 
formats by Including only those parts of an announcement thread address which 
render the address unique within the particular index message in which it is to be 
10 included, but not necessarily "globally unique. 
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